Scenario

In order to reproduce the issue reported in #8880 where onchaind makes node crashes after CLN has lost a channel state (due to database deletion/corruption) and encounters a force-close transaction containing HTLC outputs that it no longer has knowledge of.

Background

A commitment transaction with anchors typically has 5 outputs (here an example):

1. Local anchor - for fee bumping
2. Remote anchor - for fee bumping
3. to_local output - funds belonging to the broadcaster (timelocked)
4. to_remote output - funds belonging to the counterparty
   HTLC output(s) - pending payments in-flight

When a node loses its database, it loses:

• The commitment number and per-commitment secrets
• Knowledge of any in-flight HTLCs
• The scripts needed to identify and claim HTLC outputs

Test Steps

1. Create two nodes with anchors (default). l1 will lose state, l2 has a disconnect trigger on WIRE_UPDATE_FULFILL_HTLC
2. l2 funds a channel to l1 (1M sats)
3. l2 pays l1400k sats so both sides have funds
4. l1 starts a payment to l2. l2 receives the HTLC but disconnects before sending the fulfill message
5. Sign l2's commitment transaction which contains the pending HTLC (verifies 4+ outputs: 2 anchors + HTLC + balances)
6. Stop l1, delete its database
7. Restart l1 and use emergencyrecover() to stub the channel
8. Reconnect to l2, which triggers the bogus reestablish
9. The captured commitment is broadcast on-chain
10. l1's onchaind fails with "Could not find resolution for output X" because it doesn't know about the HTLC

The test will fail before its end, when l1 will resing with bitcoind, with the command sync_blockheight(bitcoind, [l1, l2])

Changelog-None